A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present invention relates generally to computer networks and, more particularly, to system and methods for facilitating the detection of events occurring in a computer network system (e.g., detection of vulnerability) and secure communication of such events within the system, as well as automated responses to such events.
The first personal computers were largely stand-alone units with no direct connection to other computers or computer networks. Data exchanges between computers were mainly accomplished by exchanging magnetic or optical media such as floppy disks. Over time, more and more computers were connected to each other using Local Area Networks or xe2x80x9cLANs.xe2x80x9d In both cases, maintaining security and controlling what information a user of a personal computer can access was relatively simple because the overall computing environment was limited and clearly defined.
With the ever-increasing popularity of the Internet, particularly the World Wide Web (xe2x80x9cWebxe2x80x9d) portion of the Internet, however, more and more personal computers are connected to larger networks. Providing access to vast stores of information, the Internet is typically accessed by users through Web xe2x80x9cbrowsersxe2x80x9d (e.g., Microsoft Internet Explorer(trademark) or Netscape Navigator(trademark)) or other xe2x80x9cInternet applications.xe2x80x9d Browsers and other Internet applications include the ability to access a URL (Universal Resource Locator) or xe2x80x9cWebxe2x80x9d site. The explosive growth of the Internet had a dramatic effect on the LANs of many businesses and other organizations. More and more employees need direct access through their corporate LAN to the Internet in order to facilitate research, competitive analysis, communication between branch offices, and send e-mail, to name just a few.
As a result, corporate IT (Information Technology) departments now face unprecedented challenges. Specifically, such departments, which have to date operated largely in a clearly defined and friendly environment, are now confronted with a far more complicated and hostile situation. As more and more computers are now connected to the Internet, either directly (e.g., over a dial-up connection with an Internet Service Provider or xe2x80x9cISPxe2x80x9d) or through a gateway between a LAN and the Internet, a whole new set of challenges face LAN administrators and individual users alike: these previously-closed computing environments are now opened to a worldwide network of computer systems. In particular, systems today are vulnerable to attacks by practically any perpetrators (hackers) having access to the Internet.
The general problem facing network environments is that security coverage/protection is generally not available 24 hours a day, seven days a week, at least not without great cost. Nevertheless, corporate networks are typically kept running at all times for various reasons, such as for hosting Web sites, FTP (File Transfer Protocol) sites, and the like. Although it is generally impractical to keep an IT team around 24 hours a day, seven days a week, corporate networks remain under constant threat of xe2x80x9cattack,xe2x80x9d from both inside and outside sources.
There are several potential sources of attack. For example, an xe2x80x9cinsidexe2x80x9d attack may occur as a result of the unauthorized act of an employee setting up a bogus FTP site, such as one containing confidential information that is not protected from access from outside the company. Another example of an inside attack is the unauthorized act of setting up a mail server (e.g., SMTP server) inside a corporate network, for sending unauthorized e-mail (e.g., completely bypassing company safeguards). xe2x80x9cOutsidexe2x80x9d attacks typically occur as a result of unauthorized access to one""s network by an outside perpetrator, that is, one existing outside the corporate xe2x80x9cfirewall.xe2x80x9d A typical example of such an attack would include unauthorized access to a valid FTP site which has accidentally been configured to have xe2x80x9cwriteablexe2x80x9d directories which are not known to exist.
Firewalls are applications that intercept the data traffic at the gateway to a wide area network (WAN) and try to check the data packets (i.e., Internet Protocol packets or xe2x80x9cIP packetsxe2x80x9d) being exchanged for suspicious or unwanted activities. Initially firewalls have been used primarily to keep intruders from the LAN by filtering data packets. More recently, the concept has been expanded to include xe2x80x9cproxy-basedxe2x80x9d firewall protection. A proxy-based firewall is one in which all relevant protocols are handled by an individual proxy, positioned (conceptually) between the incoming network card and the outgoing network card. In this manner, the proxy-based firewall can receive a connection from one side (e.g., incoming side) and apply relevant security checks before re-opening a corresponding connection on the other side (e.g., outgoing side).
Even with the availability of firewall technology, present-day techniques for detecting system compromise and vulnerabilities have occurred in a fairly non-automated fashion. Typically, an IT team routinely scans a company""s network using scanning software, reviews a report of vulnerabilities, and then decides what firewall rules, if any, should be written. A particular problem with this approach is that existing firewalls have not, to date, served as an adequate substitute for IT personnel themselves. This stems from the fact that existing firewalls are simply static in nature and, thus, are unable to participate in a proactive, or even reactive, manner. When a breach in the network security or attack occurs, a firewall can only correctly handle the event if it has been programmed beforehand (e.g., by a system administrator) with a rule appropriate for the event. Since a firewall essentially serves as a repository of static rules, its functionality is limited by the ability of its system administrator to anticipate events and create rules for handling those events.
Often, however, an event will occur for which there is no rule. Since firewall rules themselves are not proactive, the firewall itself is unable to appropriately handle the event. Thus, events often require human intervention for appropriate handling. As these attacks can happen quite rapidly, such manual human intervention is itself often inadequate. Frequently, by the time IT personnel has detected an attack, it is too late: the damage (e.g., unauthorized access to confidential information) has already been done.
What is needed is a system with methodology that provides proactive protection for computer networks, thereby eliminating the need for continual, manual supervision and intervention for securing one""s corporate network. Moreover, the underlying security and integrity of the proactive system itself should be assured, including communications within the system, so that the system itself does not introduce vulnerability to the network. In this manner, such a system may be employed to free IT personnel from the task of having to search for, and appropriately handle, system compromises in a non-automated manner. The present invention fulfills this and other needs.
System and methodology providing automated or xe2x80x9cproactivexe2x80x9d network security (xe2x80x9cactivexe2x80x9d firewall) are described. In one embodiment, a system implementing an active firewall is provided which includes methodology for verifying or authenticating communications between network components (e.g., sensor(s), arbiter(s), and actor(s)), using cryptographic keys or digital certificates. Certificates may be used to digitally sign a message or file and, in a complementary manner, to verify a digital signature. These xe2x80x9cdigital signaturesxe2x80x9d allow authentication of messages, such that forgery of a signed message is not computationally feasible.
A methodology of the present invention for providing an active firewall may be summarized as follows. At the outset, particular software components that may participate in authenticated communication are specified, including creating a digital certificate for each such software component. The system has been configured by a system administrator for specifying which components of the system may participate in the process. Next, an event of interest occurs in the system, such as detection of a compromise or vulnerability in the system by a sensor (e.g., scanner). Upon occurrence of the event, the sensor component communicates information about the event in a secure, authenticated manner with another xe2x80x9clistenerxe2x80x9d component, an arbiter or Event Orchestrator (EO).
Because of the system""s existing configuration, the system already stores in its repository signed digital certificates (i.e., signed by the system administrator) for the two components, so that the components can proceed to engage in a digital conversation (i.e., communication session). Here, the sensorxe2x80x94acting as a xe2x80x9csenderxe2x80x9dxe2x80x94invokes the following substeps for effecting authenticated communication with one or more listeners. First, the sender creates a xe2x80x9ccertogramxe2x80x9dxe2x80x94that is, a packet of information describing the event which is organized into a format suitable for transmission. In the currently-preferred embodiment, a certogram may be constructed using attribute/value pairs in plain text, such as  less than attribute greater than = less than value greater than , with a delimiter employed for separating one pair from the next. The sender determines which component(s) are its listeners. This determination is performed by simply enumerating those component(s) that have been specified in the system configuration to be listeners for this component (e.g., sensor). The components in the system may be specified by an IP (Internet Protocol) address or other identification scheme.
Now, a socket connection may be established. In the currently-preferred embodiment, this is performed through PGP(trademark) TLS using a sequence of API (application programming interface) calls into the PGPsdk(trademark) run-time library. Here, the component opens a socket connection (communication to a particular IP address on a particular port), binds that to a session, and then broadcasts a message to that port announcing its presence. At this point in the process, the communication socket is simply a conventional stream socket; communication is not yet authenticated. If a listener is present, that listener will respond with an acknowledgment accepting the socket connection. An acknowledgment may be received back from one or more listeners. Now that the communication layer is established, the method may proceed to the next substep, for exchanging certificates with the listener(s).
The respective sender/listener(s) components each validate the certificate received from the other. Validation may proceed in a conventional manner, for example using X.509 validation, including determining the level of trust and validity (including, for instance, the expiration, revocation, and disablement) of a given certificate. If each respective component is able to successfully validate the certificate received from the other, secure communication ensues. From that point on, communication occurs in a secure, authenticated manner, with each message or blob being digitally signed or fingerprinted, for instance, using a cryptographic hash or message digest. Any alteration to the message breaks the digital fingerprint and, therefore, may easily be detected. If desired, encryption may also be (optionally) applied to the communication messages. In those embodiments intended for export from the United States, however, encryption may be limited (e.g., as to key length) or removed.
Upon return back to the main or controlling method (i.e., after completion of the foregoing substeps), the listener(s) decides whether to act on or pass on the event reported by the certogram, or simply to ignore it. If the event is not to be acted on or passed on, the method is done. Typically, however, the reported event maps to a script-defined event handler in the listener (e.g., Event Orchestrator or EO) which, in turn, desires to notify yet another listener, the actor (e.g., firewall). Communication may therefore continue with the arbiter (EO) communicating with the target actor(s) in an authenticated manner, as above, with the arbiter (EO) as the sender and the actor (firewall) as the listener. The actor or firewall, upon receiving the certogram, may now undertake appropriate action, such as dynamically creating or modifying rules for appropriately handling the event, or it may choose to ignore the event (e.g., if the event is a duplicate of a previous event or if the event is covered by (or is a sub-set of) an existing firewall rule).